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What is the “Digital Documentation of COVID-19 Certificates: (GR, World Health 


(Ree 
wax apy, 


Organization 


Vaccination Status Technical Specifications and Implementation ~~ 
Guidance” document? 


The “Digital Documentation of COVID-19 Certificates: 
Vaccination Status (DDCC:VS) Technical Specifications and 
Implementation Guidance” document is a baseline 
requirements document for technology partners that are 
creating or overseeing the development of a digital 
vaccination certificate solution for COVID-19. It is written so 
that Member States: 


Y Do not oversimplify the development of digital 
vaccination certificate solutions, at the risk of 
compromising ethical and data protecting design 
choices; 


Y Can adopt and adhere to digital health interoperability 
standards; 


V Have the flexibility to determine which digital solutions 
work best for their context and local technology partners. 
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The “DDCC:VS Technical Specifications and 
Implementation Guidance’ Is 


NOT A POLICY DOCUMENT. 


Policy guidance regarding the use of COVID-19 vaccination 
certificates is available in the following WHO guidance 
documents: 


™ Technical considerations for implementing a risk-based 
approach to international travel in the context of 
COVID-19: Interim guidance, 2 July 2021 


> Policy considerations for implementing a risk-based 


approach to international travel in the context of 
COVID-19 


[> Interim guidance on considerations for implementing 


and adjusting public health and social measures in the 
context of COVID-19 


What is a DDCC:VS? 


> Digital Documentation of COVID-19 


Certificates, or DDCC:VS, is a digitally signed 
representation of data content that describes a 
vaccination event. DDCC:VS data content 
respects the specified core data set and follows 
the Health Level Seven (HL7) Fast Healthcare 
Interoperability Resources (FHIR) standard 
detailed in the FHIR Implementation Guide. 


The International Certificate of Vaccination or 
Prophylaxis and a national immunization home- 
based record are not considered DDCC:VS 
because they are not available in a digital format 
and do not meet the requirements outlined in 
this technical specifications and implementation 
guidance document. 
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A handwritten paper 
certificate with a 2D 
barcode containing the 
full DDCC:VS core data set 
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A PDF print-out 
certificate with onlya 
HCID which links toa 
DDCC:VS 


OR 


A PDF print-out witha 

2D barcode containing 

the full DDCC:VS core 
data set 
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A DDCC:VS 
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What can the DDCC:VS be used for? £4) Organization 


Proof of 
Continuity of Vaccination 
Care scenario scenario 


The vaccination certificate is presented to a medical The vaccination certificate is presented as proof that the 
authority so that the bearer’s vaccination status can be bearer has received vaccine for COVID-19, and this claim 
(oo) aki (ol=1n=10 ir- kom of- | me) m@e) audi ale] i ale mKom ©) ce)Vle(-me-]a-mcomial= can be checked and validated by an interested party. 


Tate fhvitolUr-] Fa tame) ga alow oy-Tamre)mndal—m 01-160) al-] mal-r-]ida Mg -1e0)] Kep ee braces 
> Establishes the vaccination status of individuals in 


> Provides a basis for health workers to offer a subsequent ofo)V{=1e- 16 [=m aa lelalixe)aialemcielaVien vis 


dose and/or appropriate health services ent * 
Establishes vaccination status after a positive COVID-19 


PT aevile(=smxelal=rel Ol (sm laicelaaatsidce)amielar-)amlarel\vs(eler-| mem <are)\ test, to understand vaccine effectiveness 
VV at=¥e aY=) ar) ale) al=) axel @kx—emr-) ale me) mii allel am\s-(eel| al=emn ism alsr=vel=ver 
ETAvemlViatclamuarem areyamrelessiomicwe [Ul- For work 


Enables investigation into adverse events by health For university education 
workers, as per existing guidance on adverse events 


SG ea mela laikclaatcialelare| munch ico) ie 
iro)| (oy ale mianlanlelaly4-1alolam¢.\=ia 0m Q/-leellalcmcy-1K-181) 


ud (alm dal-movo)alx->.ameyimlaic-)aar-ldle)al-]mue-).-) Aa [ale- ever) cel-laleomWiiNam-le\{(e-mice)anmaal-moldaMmaal-1-dale me)maal-m lale-ieat-lilelare] 
Health Regulations (2005) Emergency Committee on COVID-19, held on 14 July 2021, countries should 
faXolana =e [0] | n-m ©) cele) me) @@)Vs (Dim bcm 7-(ecel|at-lile)amr-\om- mere)atefid(o)amie)an une) -1R 
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What is the data required for a DDCC:VS? 


Data requirements will depend on the scenario of use and the format of the DDCC:VS. Member States will need to determine whether they 
want to include Optional data elements, depending on the local context and agreements that establish trust with other Member States. 





Requirement Requirement 
status for status for Proof of Data Element Label Description and Definition 
Continuity of Care Vaccination 
REQUIRED REQUIRED Header — NAME The full name of the vaccinated person. 
REQUIRED REQUIRED input once DATE OF BIRTH The vaccinated person's date of birth (DOB) if known. If unknown, use assigned DOB for administrative purposes. 
OPTIONAL OPTIONAL UNIQUE IDENTIFIER Unique identifier for the vaccinated person, according to the policies applicable to each country. There can be more than one unique 
identifier used to link records (e.g., national ID, health ID, immunization information system ID, medical record ID). 
OPTIONAL NOT NEEDED SEX Documentation of a specific instance of sex information for the vaccinated person. 
REQUIRED REQUIRED Data VACCINE OR PROPHYLAXIS Generic description of the vaccine or vaccine sub-type, e.g., COVID-19 mRNA vaccine, HPV vaccine. 
REQUIRED REQUIRED needed for VACCINE BRAND The brand or trade name used to refer to the vaccine received. 
CONDITIONAL CONDITIONAL each VACCINE MANUFACTURER Name of the manufacturer of the vaccine received. e.g., Serum institute of India, AstraZeneca. If vaccine manufacturer is unknown, 
vaccination market authorization holder is REQUIRED. 
CONDITIONAL CONDITIONAL event VACCINE MARKET Name of the market authorization holder of the vaccine received. If market authorization holder is unknown, vaccine manufacturer is 
AUTHORIZATION HOLDER REQUIRED. 
REQUIRED REQUIRED VACCINE BATCH NUMBER Batch number or lot number of vaccine. 
REQUIRED REQUIRED DATE OF VACCINATION Date in which the vaccine was provided. 
REQUIRED REQUIRED DOSE NUMBER Vaccine dose number. 
OPTIONAL OPTIONAL VACCINATION VALID FROM Date upon which provided vaccination is considered valid. This data should only be considered valid at the time of issuance, as 


guidance is likely to evolve with further scientific evidence. Any user of this data (Vaccinator, Verifier) should validate this date 
according to their national policy. In the case of repeated doses, the data field for a subsequent dose should override the data field for 
a predecessor dose. 


OPTIONAL OPTIONAL TOTAL DOSES Total expected doses as defined by Member State care plan and immunization programme policies. 
REQUIRED REQUIRED COUNTRY OF VACCINATION The country in which the individual has been vaccinated. 
REQUIRED OPTIONAL ADMINISTERING CENTRE The name or identifier of the vaccination facility responsible for providing the vaccination. 
OPTIONAL CONDITIONAL SIGNATURE OF HEALTH REQUIRED for PAPER vaccination certificates that have been filled out with handwriting ONLY. A printed paper vaccine certificate 
WORKER does not require the handwritten signature of a health worker. The health worker who provided the vaccination or the supervising 
clinician's hand-written signature. 
OPTIONAL OPTIONAL HEALTH WORKER IDENTIFIER OPTIONAL for DIGITAL and PAPER vaccination certificates. The unique identifier for the health worker as determined by the member 


state. There can be more than one unique identifier used. (e.g., system generated ID, health profession number, cryptographic 
signature, or any other form of health worker unique identifier). This can be used in lieu of a paper-based signature. 
OPTIONAL OPTIONAL DISEASE OR AGENT TARGETED Name of disease vaccinated to protect against (such as COVID-19). 
OPTIONAL NOT NEEDED DUE DATE OF NEXT DOSE Date on which the next vaccination should be administered, if a next dose is required. 
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What ts the standard operating procedure for 
implementing DDCC:VS? 


START 


Determine the intended uses for a 
digital vaccination certificate system. 


The value proposition of digitizing a vaccine 
certificate will need to be clear. 


See Table 1 in the Executive Summary for the 
multiple uses of a DDCC:VS. 





Determine whether to leverage 
existing digital systems that 
document vaccination status or adopt 
a new system. 

This should be based on the existing digital 


health enterprise architecture and the country’s 
overall digital health strategy. 


See section 8 for additional implementation 
considerations. 
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Conduct an impact assessment to 
understand the potential risks, 
benefits, and costs for establishing a 
DDCC:VS. 


Use this to inform the design of your system and 
key policy decisions. 


See section 2 for recommendations on ethical 
and privacy protecting design, development, and 
implementation of DDCC:VS. 


Gather health content requirements 
and system requirements for the 
intended use of your DDCC:VS. 


This document focuses on providing the 
technical specifications necessary to create an 
interoperability standards-based DDCC:VS. The 
system requirements should be informed by the 
supporting policy and legal framework, including 
the ethical and privacy considerations. 


See sections 3, 4, 5, and 6 for workflows, data 
requirements, and functional requirements for 
the various scenarios of use of a DDCC:VS. 


KS 


YN 
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Establish policies and a legal 
framework to support your intended 
uses of the DDCC:VS. 


Countries should have policies and a legal 
framework for appropriate use, data protection, 
and governance of the DDCC:VS to reduce the 
potential harms, while achieving the public health 
benefits. This includes any relevant national or 
international policy agreements. 


See section 1.6 for a list of other WHO policy 
guidance publications and section 7 for 
additional governance considerations. 


Develop, deploy, implement, and 
scale your DDCC:VS solution. 


A clear mechanism for obtaining and responding 
to feedback from end users will need to be 
established, including a mechanism to 
consistently push updates. 


See section 8 and the Digital Health 
Implementation Investment Guide (DIIG) for 


additional details. 





The design of the DDCC:VS solution should depend on 


feasibility of implementation 


The availability of infrastructure at the Care Site will determine the possible format in which a DDCC:VS can be issued. 
The availability of infrastructure where proof of vaccination is needed will determine the mechanism for which verification can be done. 


Scenarios for issuing DDCC:VS 


Paper first 


* Health certificate identifier (HCID) barcode is pre- 
printed on a paper card. 


* Core data set is expected to be handwritten. 


* Data about the vaccination event is entered into 
a Digital Health Solution afterwards to create a 
digital record. 


Offline digital 
HCID barcode is pre-printed on a paper card. 
Core data set can be printed or handwritten. 


Data about the vaccination event is recorded 
using an offline Digital Health Solution, with the 
content uploaded once connectivity is available. 


Online digital 

* The HCID barcode can be printed at the same 
time as the core data set at the time of the 
vaccination event. 


* The Digital Health Solution can update the data 
about the vaccination event in real time. 


me) aait:1 cme) mB) DIG GaAs 


Handwritten paper certificate with only an HCID 


Possible issuing scenarios: @hiillal-melte fit] 


Handwritten paper certificate with a 2D barcode 
containing the entire DDCC:VS core data set. 


*This will need to be provided to the DDCC:VS Holder after the 
vaccination event. 


Possible issuing scenarios: @hiillar-melte fixe 


PDF print out with only an HCID 


Possible issuing scenarios: (@)iilty-welfelic-l) KOlalilarcmelfe lite) 


PDF print out with a 2D barcode containing the 
entire DDCC:VS core data set. 


*This will need to be provided to the DDCC:VS Holder after the 
vaccination event. 


Possible issuing scenarios: (@yilist-elfeyieih COla\iatemel fe lhe 


A DDCCGNS held on a smartphone application 


Possible issuing scenarios: (@yg\itat=xeltelit] 
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Scenarios for verifying DDCC:VS 


Offline status check 


Manual verification 

A Verifier verifies a DDCC:VS by looking at the certificate 
and decides its legitimacy based on their subjective 
judgement. No digital technology is required. 


Offline cryptographic verification 
A Verifier verifies a DDCC:VS using digital cryptographic 
processes in an offline mode. 


*Only possible with DDCC:VS formats that contain a 2D barcode with 
the entire DDCC:VS core data set or a smartphone application 


Online status check 


National DDCC:VS 

Uses digital cryptographic processes in an online mode 
that includes a status check against the PHA’s DDCC:VS 
Registry Service and optionally the DDCC:VS Repository. 


International DDCC:VS 

Uses digital cryptographic processes in an online mode 
that includes a status check against the National PHA’s 
DDCC:VS Registry Service; and an International PHA's 
DDCC:VS Registry Service and optional Repository, if such 
services exist and agreements for use are in place. 





What are the key considerations to determine the 
format of the DDCC:VS? 


The selected design format, or formats, of the DDCC:VS will have implications on how the content of the DDCC:VS is stored and verified. 


STORED DDCC:VS FORMAT (DDCC:VS CONTENT STORED IN A CENTRAL REPOSITORY): 





> Leverages a centrally stored copy of the signed DDCC:VS content; 


Handwritten paper certificate with only 
an HCID > The HCID on the paper certificate is used as a “lookup token"; 


> Verifiers can use the HCID for online retrieval of the digitally signed DDCC:VS document from a central 


web service; 
PDF print out with only an HCID 


> Verifiers can confirm if the online content matches the content on the DDCC:VS paper certificate; 


> Requires online access for verification (no offline digital verification option). 


DISTRIBUTED DDCC:VS FORMAT (DDCC:VS CONTENT IN A 2D BARCODE): 


Handwritten paper certificate with a 2D = , e : : 
barcode containing the entire DDCC:VS > Digitally signed 2D barcodes as the verifiable DDCC:VS format will require that each issuer can: 


eras . Generate a 2D barcode from the DDCC:VS document: 


PDF print out with a 2D barcode . Digitally sign the 2D barcode using a Document Signer Certificate (DSC); and 


ining th ire DDCC:VS dat 
oo a —_—— . Distribute the 2D barcode to DDCC:VS Holders. For DDCC:VS Holders who do not have 


smartphones, 2D barcodes would need to be printed for them. 


A DDCCVS held on a smartphone > Verifiers will need to leverage an application to read the 2D barcode and verify both its content and its 
application digital signature. To work offline, the application will need to have downloaded the necessary DSC 
public keys. 
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What are the architecture implications for issuing and 


verifying DDCC:VS? 
Some centralized infrastructure is required regardless of DDCC:VS format, as the DDCC:VS Digital Health Solutions will need to be able to 
generate and sign the DDCC:VS. At least one DSC is needed with information about each DDCC:VS saved to a DDCC:VS Registry Service. 


Centralized 
Vrdalicsaela: 


Decentralized 
Vrgalicseaela: 


Implications on Issuing DDCC:VS 


> A centrally-deployed DDCC:VS generation service may 
be leveraged by the entire ecosystem. 


> PKI requirements are significantly simplified. 


> Centralized solutions present a single point of failure, 
so service level requirements can be onerous. 


> There may be regulatory and/or data governance 
challenges associated with centralized processing. 


> If there are multiple DDCC:VS issuers (e.g., hospitals, 
pharmacies, etc.), each QR code issuer will require a 
Document Signer Certificate (DSC). This will require 
national public key infrastructure (PKI) and Public 
Key Directory (PKD) deployment. 


> Printing capacity would need to be widely available so 
that DDCC:VS Holders without a smartphone can receive 
a printed QR code. 
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Implications on Verifying DDCC:VS 


> Only the HCID is needed to do an online lookup of the 
DDCC:VS content. 


> Network access is required for verification against the 
central server; it does not work in offline mode. 


> Revoked certificates can be identified. 
> A Public Key Directory (PKD) is not required. 


> Citizens’ concerns regarding data privacy and online 
surveillance may need to be addressed. 


> Each verifier needs a QR code reader which can: 


¢ Access and download the public keys (e.g., from a 
global PKD) of every QR code issuer. 


¢ Decode each supported QR code format (e.g., EU DCC, 
ICAO VDS-NC). 


> The reader supports offline verification. 


> Certificate revocation is not supported. 





HCID: health certificate identifier; EU DCC: European Union Digital COVID Certificate; ICAO: International 
Civil Aviation Organization Visible Digital Seals for Non-Constrained environments 


What are the digital health interoperability 


‘ @) World Heatth 
standards required? ES Organization 


> The preferred semantic standard is the International Classifications of Diseases, 11 edition (ICD-11) 


¢ ICD-11 is recommended as the most suitable and future-proof value set for use in the DDCC:VS data dictionary. Implementers 
may use the DDCC:VS core data set as defined or may continue to use their existing terminology with a map to the 
DDCC:VS core data set data elements, so long as it contains the required data elements in the DDCC:VS core data set. The 
recommended core data set is intended to include the critical data required for interoperability, specific to the scenarios of use 
defined, and driven by the public health need. 


> The preferred syntactic standard is Health Level Seven (HL7) Fast Healthcare Interoperability Resources (FHIR)® 


¢ The FHIR implementation guide for DDCC:VS contains a standards-compliant specification that explicitly encodes computer- 
interoperable logic, including data models, terminologies and logic expressions, in a computable language sufficient for 
implementation of continuity of care and proof of vaccination use cases. 


> Additional details can be found on the DDCC:VS FHIR Implementation Guide, accessible at: 
https://WorldHealthOrganization.github.io/ddcc 
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